Using .net Objects

Modified on 2012/02/21 18:55 by John — Categorized as: Release Notes

Using .Net Objects within Jetfire (V1.3.6+ )¶

Beginning with release V1.3.6 of the Jetfire download .net objects (CLR objects) can be used directly within Jetfire with a few restrictions. Dot net object support will be phased in over a number of releases beginning with V1.3.6.

Static methods and properties of a .net class can be used exactly like Jetfire class within Jetfire.
Instance methods and properties of a .net object can be used exactly like Jetfire object within Jetfire (V1.3.12) (see Restrictions below).
Clr (.net) objects can be passed as parameters to Jetfire methods (V1.3.12).
The 'new' construct can be used for .net objects (to be completed)
References to .net object will not be made persistent unless they support (to be completed)
- ISerializable (exact serialization mechanism is TBD - see comparison article for issues)
- INotifyPropertyChanged
CLR objects and classes must be made known to Jetfire through an application interface method called "AddClrClass(System.Type)". This method needs only only to be executed once as the type information will be stored in in a workflow class in the server nexus.
- Changes to the CLR class may break Jetfire code. TBD - how to allow changes to CLR code?

Restrictions - V1.3.12¶

There are currently a number of restrictions for the usage of clr objects within Jetfire. It is expected that these restrictions will be eased in the near future.

Clr objects may only be passed as method parameters.
- Clr object types may not be used to declare fields in a Workflow or method.
The 'new' construct can not be used for clr objects.

Internal Implementation¶

Jetfire stores the 'Class name' (and the assembly name) when the method "AddClrClass(System.Type)" is invoked. Each time a client nexus is started the Jetfire code is parsed, compiled and bound to the CLR static methods, properties and fields. Naturally the CLR code could change between client nexus invocations.

Should the CLR code change to prevent the Jetfire code from compiling the client nexus will start; however the Jetfire classes (parse units) may be marked broken if Jetfire is unable to deserialize the object.

The system implementer is responsible for managing revisions/updates/distribution/verification of CLR code that is bound in with Jetfire.

Serializing Clr Objects (to be implemented)¶

A Clr object type can be used in workflow field declaration. Jetfire will serialize the field's Clr object in a Xml readable format to be stored in the server nexus. The Jetfire will use the appropriate serializer.

The ISerializable interface will be used if the Clr object supports this interface.
The XML Serializer will be used if the Clr object supports the 'IXMLSerializable' interface.
If no serializer is specified the Jetfire serializer will be used. The Jetfire serializer works like the XmlSerializer; however it supports 'Timespan', circular references and changes to Clr class.

Example Jetfire Code¶